TITLE OF THE INVENTION 

STATUS SETTING SYSTEM AND METHOD 

BACKGROUND OF THE INVENTION 

Technical Field 

The present invention relates to technologies for sharing 
a virtually constructed space on a network and for notifying 
other users of user status such as attendance or absence. The 
present invention more particularly relates to technologies 
that enable each user to share the status on every individual 
user on the same virtual space. 

Description of Related Ae£ 

In present invention, a chat system is configured to 
include multiple chat devices . The chat device is connected to 
a network. Each user can receive and send text messages through 
a shared virtual space set up on a network. The chat device can 
display a text message to be sent or received. IRC (Internet 
Relay Chat) f forums on Nifty, and WebChat are examples of chat 
systems. 

IRC is one type of chat system constructed in compliance 
with the IRC protocol (RFC1459). An IRC system is constructed 
by connecting IRC servers to its clients via the Internet. The 
IRC client shares a virtual space, called a channel, and sends 
and receives text messages in real time. The IRC server 
broadcasts messages to the IRC clients that share the same 
channel. In an IRC system, each IRC client is uniquely 



designated by an identifier called a nickname. 

WebChat is a chat system constructed with WWW servers and 
WWW browsers on the Internet. In this case, users converse by 
viewing text messages or sending their own messages after 
accessing a Web page. For WebChat, a real-time chat system is 
provided. 

The chat support device in the present invention operates 
on a user terminal together with the chat device. The chat 
support device sends and receives the status of users sharing 
a virtual space, and displays them with conversation contents. 

A communication system is diffused in a virtual space on 
a network on which communications are performed. IRC, forums 
on Nifty, and WebChat are examples of chat systems on which a 
user can send and receive text messages in real time in virtual 
space. In IRC, chat clients who operate user terminals enter a 
particular virtual space denoted by its channel, and the chat 
clients can converse with other users on the same channel by 
characters in real time. 

In a real-time chat system as typified by a chat system, 
messages can be sent in real time and at any time. Thus, 
activities of other users can be easily interrupted. There is 
a growing need to communicate in ways that are considerate to 
the status of other users. For example, the status of one user 
may indicate that he/she is willing to receive messages. 



Alternatively, the status may indicate that the user is busy and 

does not wish to be disturbed. 

Responding to the aforementioned need, Japanese Laid-Open 

Pat. App. 1999-185802 provides a chat support device that allows 
5 users to share each user's status, and allows users to converse 

even if other users in a virtual space enter or leave the space. 

With this chat support device, the status of users participating 

in the virtual space is displayed on a screen. Users who newly 
P connect to the virtual space make their status known to other 

\i io previously connected users. These notifications are received by 
m other chat support device in the virtual space and displayed on 

M- terminals of other users. 

s Conversely, if any of the users withdraws from the virtual 

^ space, the chat support device detects the withdrawal and 

J? 15 deletes the status display of the relevant user. By using the 
^ chat support device, users can share the status of other users, 

even users enter into or leave from virtual space change. A 
user's status is detected by a detection part of a user terminal. 
Alternatively, a user's status can be set by the user. 
20 Normally, participating users and/or topics in a virtual 

space can completely change depending on the virtual space. 
Accordingly, the status to be notified or the status of another 
user to be known often varies depending on properties of the 
virtual space. For example, salespersons in a company may notify 
25 their status using identifiers such as "Outside work" or 



"Dealing with a customer" in their virtual space- On the other 
hand, researchers may notify their status using identifiers such 
as "Performing an experiment" or "Paperwork" in their virtual 
space. It is convenient that different status identifiers in 
each virtual space can be set according to each virtual space. 

However, in Japanese Laid-Open Pat* App. 1999-185802, a 
status identifier of one user is common to all virtual spaces 
and limited to one status* On this account, there is a problem 
that each virtual space cannot be. notified different status 
identifiers according properties of virtual spaces . 
Furthermore, a status identifier that a user can specify is 
limited to those predetermined by a system. Therefore, status 
identifiers cannot be set according to properties of the virtual 
space. 

Status identifiers may need to be changed according to the 
role of a user in a virtual space. For example, a status set by 
a student should be different from a status set by a teacher in 
a virtual space where a teacher conducts an online class with 
students. The students may wish to set status identifiers such 
as "Yes," "No," "Hard to understand," or "Understand." The 
teacher may wish to set a status identifier such as "Accepting 
questions," or "Explaining." If all of these status identifiers 
can be selected regardless of the role of users, problems may 
occur if students can select a teacher's status identifier or 
vice versa. 



SUMMARY OF THE INVENTION 

The object of the present invention is to provide 
technologies for status setting suitable for properties of each 
virtual space to promote smooth communication. 

To solve the problem, a first aspect of the present 
invention provides a status setting method in which a user 
terminal can send, receive, and display a user status and a 
character message by sharing one or more virtual spaces set up 
on a network comprising; 

preparing a status table in which configurable user 
statuses are registered for each virtual space; 

obtaining the status table of a virtual space in which a 
user terminal participates every time the user terminal 
participates in the virtual space; 

setting a user status on each virtual space for the virtual 
space based on an obtained status table; and 

sending to, receiving from, and displaying for each 
virtual space the user status set for each virtual space. 

A user status suitable for properties of a virtual space 
is registered on a status table of the virtual space. For example, 
a status identifier such as "Present," "Absent," "Dealing with 
a customer," or "Outside work" is registered on the status table 
of a virtual space in which salespersons participate. Meanwhile, 
a status identifier such as "Performing an experiment," 



"Paperwork," or "In conference" is registered on the status 
table of a virtual space in which researchers participate. A user 
obtains a status table of a participating virtual space by some 
method. Any of the user statuses registered on the status table 
is selected and set as the status on the virtual space. Either 
manual selection by a user or automatic selection by some method 
can be accepted. The set user status is notified to the same 
virtual space. 

A second aspect of the present invention provides a status 
setting method as set forth in the first aspect, wherein the user 
status and a user attribute defining configurable user statuses 
are correlatively registered in the status table. 

For example, the status identifiers from which a student 
may choose should be different from the status identifiers of 
a teacher in a virtual space where an online class is conducted. 
In this case, correspondence between a user attribute such as 
"Student" or "Teacher" and a status that can be set in the 
attribute is set and registered in a status table. 

A third aspect of the present invention provides a status 
setting method as set forth in the first aspect, wherein a common 
table in which prescribed user statuses are registered is 
previously prepared. The common table is obtained if no status 
table is prepared for a virtual space in which user terminals 
participate, and a user status on the virtual space is set for 
the virtual space based on an obtained common table. A common 
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table is prepared just in case that no status tables are prepared 
for a virtual space in which user terminals participate. 

A fourth aspect of the present invention provides a status 
setting method as set forth in the first aspect, wherein setting 
of a user status by a user is accepted. 

For example, adding a user status to a status table or 
changing a user status on a status table is accepted from an 
administrator of the virtual space, A user status suitable for 
properties of the virtual space can be set or- notified. 

A fifth aspect of the present invention provides a status 
setting method as set forth in the first aspect, wherein if said 
user terminal can display a user status with a symbol, and the 
user status and the symbol are correlatively registered in a 
status table- A status of another user sharing a virtual space 
is displayed with a symbol relating to the user status . For 
example, assume that a user status identifier "Absent" is 
related to an "Absence" icon. In this case, the "Absence" of the 
user in the virtual space is notified to other users by 
displaying the "Absence" icon. 

A sixth aspect of the present invention provides a status 
setting method as set forth in the first aspect, wherein a list 
of user statuses registered in an obtained status table is 
displayed independently on each virtual space in which user 
terminals participate. Selecting any of the user statuses on 



the list for each virtual space is accepted in order to set a 
user status for each virtual space. 

For example, a Self Status Setting Menubar is provided in the 
window where conversations on a virtual space are displayed. 
5 When a user presses the Self Status Setting Menubar, a list of 
settable statuses of that virtual space is displayed and the user 
can select any of the statuses. 

A seventh aspect of the present invention provides a 
computer-readable recording medium having a status-setting 
10 module for executing the method set forth in any of the first 
to sixth aspects of the invention. Herein a computer^readable 
medium is preferably a floppy disk, hard disk, semiconductor 
memory, CD-ROM, DVD, MO, etc. 

An eighth aspect of the present invention provides a 
15 transmission medium transmitting a status setting module for- 
executing a method set forth in any of the first to sixth aspects 
of the invention. Herein a transmission medium is preferably a 
communication medium on a computer network system (LAN, Internet, 
or radio communication network) for transmitting and providing 
20 module information as a carrier wave, a fiber optic, or a radio 
circuit. 

A ninth aspect of the present invention provides a status 
setting system comprising user terminals, a storing means, an 
obtaining means, a setting means, and a displaying means. The 
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user terminals can send and receive user statuses and character 
messages by sharing one or more virtual space set on a network. 

The storing means stores a status table on which 
configurable user statuses are registered is stored for each 
virtual space. The obtaining means obtains the status table of 
a virtual space in which a user terminal participates every time 
a user terminal participates in the virtual space. The setting 
means sets a user status on each virtual space for each virtual 
space based on an obtained status table. The displaying means 
receives from, sends to, and displays for each virtual space the 
user status set for each virtual space. 

The ninth aspect of the present invention has the same 
effect as the first aspect of the invention. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a function configuration diagram according to 
a first embodiment of the present invention. 

Fig. 2 is a flowchart illustrating flow of a monitoring 
process in accordance with the first embodiment of the present 
invention . 

Fig. 3 is a flowchart illustrating flow of an obtaining 
process in accordance with the first embodiment of the present 
invention. 

Fig. 4 is a flowchart illustrating flow of a setting 
process in accordance with the first embodiment of the present 
invention. 



Fig- 5 is a flowchart illustrating flow of a registration 
process in accordance with the first embodiment of the present 
invention . 

Fig. 6 is a conceptual explanatory diagram of status 
tables stored in a dedicated terminal in accordance with the 
first embodiment of the present invention. 

Fig. 7 is a display example of Setting Window when plural 
channels are independently displayed in accordance with the 
first embodiment of the present invention. 

Fig. 8 is- a display example of Setting Window when one 
channel is independently displayed in accordance with the first 
embodiment of the present invention. 

Fig. 9 is a display example of Register Window in 
accordance with the first embodiment of the present invention. 

Fig. 10 is a display example of Register Window setting 
a status table in accordance with the first embodiment of the 
pr es ent invent ion . 

Fig. 11 is a conceptual explanatory diagram of an icon list 
stored in a dedicated terminal in accordance with the first 
embodiment of the present invention. 

Fig. 12 is a conceptual explanatory diagram of a virtual 
space table created by a status setting device in accordance with 
the first embodiment of the present invention. 



Fig. 13 is a conceptual explanatory diagram of another 
icon list stored in a dedicated terminal in accordance with the 
first embodiment of the present invention. 

(a) Fundamental icon list 

(b) Auxiliary icon list 

Fig. 14 is a function configuration view of the status 
setting system according to a second embodiment of the present 
invention* 

Fig. 15 is . a function configuration view of the status 



io setting system according to a third embodiment of the present 
y=j invention. 

M> DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

* The following explains in detail the status setting system 

H according to the present invention, referencing the drawings. 

J? is Fig. 1 is. an overall block diagram of the status setting 

w system according to the first embodiment. In this system, a 

status setting device 1 operates with an IRC client 2 and a chat 
support device 3 on a user terminal 4. This user terminal 4 is 
connected to a dedicated terminal 6 via a network 5. 
20 A status table storing settable user statuses is stored 

in the dedicated terminal 6 . A common table storing settable 
statuses in all channels is also stored in the dedicated terminal 
6. Furthermore, an icon file that represents users in a channel 
and their respective statuses is stored in the dedicated 
25 terminal 6. These tables and a required icon file are supplied 
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to a user terminal 4 by a supply module 61 according to a request 
from the status setting device. For example, an IRC server or 
a bot on an IRC system can be used as the dedicated terminal 6 - 
An independent information terminal can also be used as the 
5 dedicated terminal 6 . 

The status setting device 1 operates mainly with an 
obtaining module 11, a setting module 12, and a registration 
module 13. The obtaining module 11 obtains a status table of 
-a channel in which an IRC client 2 participates from the 
10 dedicated terminal 6. The setting module 12 accepts a selection 
of any status from a status table of each channel. The 
registration module accepts from a user a setting of a status 
table reflecting properties of a channel and registers it to the 
dedicated terminal 6 . 
15 The status setting device has a monitoring module 14, a 

symbol module 15 and a storage part 16 in addition to the above 
modules. The monitoring module 14 monitors occurrence of 
prescribed events and operates according to an event that 
occurred. The symbol module 15 administrates icons represent 
20 users in a channel and their statuses. The storage part 16 
retains a status table in which users previously participated. 

The following explains a process flow of the status 
setting device 1 having the functions mentioned above. 
( 1 ) Monitoring module 
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Fig. 2 is a flow chart showing the flow of processing 
performed by the monitoring module. In this process, the status 
setting system 1 monitors occurrence of prescribed events and 
performs a process according to an event that occurred. The 
5 prescribed event means participation in a new channel and switch 
a current displayed channel to another. The current channel 
means a channel that is designated by a user as a display object 
and a sending-message object. 

In step SI , the. status setting device 1 determines whether 
10 or not the IRC client 2 newly joined in a channel.. If the status 
setting device 1 determines that the result is "Yes," then step 
S2 ensues. If the status setting device 1 determines that the 
result is "No," then step S3 ensues. 

In step S2, the status setting device 1 executes an obtaining 
15 process, which will be described later. Specifically, the status 
setting device 1 performs a process for obtaining the status 
table of a channel in which the IRC client 2 newly participates 
or the common table, and the icon file from the dedicated 
terminal 6. 

20 in step S3, the status setting device determines whether 

or not the current channel has changed or not. The current 
channel can be obtained from the IRC client 2. If the status 
setting device 1 determines that the result is "Yes," then step 
S4 ensues. If the status setting device 1 determines that the 

25 result is "No," then the status setting device 1 returns the 
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process to step SI and repeats the aforementioned processes. 
However, step S3 is performed only if the IRC client 2 
independently can display one channel because in this case, a 
settable user status changes depending on the channel changes 
that are displayed. 

In step S4, the status setting device 1 changes a status 
table to be displayed. Specifically, the status setting device 
1 performs a process such as loading a status table of a channel 
that newly becomes a . current channel in a display buffer. 
Contents that are loaded in the display buffer are displayed by 
a setting process, which will be described later. 

(2) Obtaining module 

Fig. 3 is a flowchart showing the flow of processing 
performed by the obtaining module. Fig. 3 also shows the flow 
of a processing performed by the dedicated terminal 6 according 
to a process of the obtaining module. If the IRC client 2 
participates in a new channel, the following process starts. 

Step Sll determines whether or not status tables in which 
a user terminal participates are stored in a storage part 16 such 
as a hard disk. As described later, if the channel is previously 
participated in, the status table is stored in the storage part 
16 just in case the channel is participated in again. If the 
status setting device 1 determines that the result is "Yes," then 
step S12 ensues. If the status setting device 1 determines that 
the result is "No," then step S13 ensues. 



In step S12, the status setting device 1 loads the status 
table that is already stored in a display buffer from the storage 
part 16. In step S13, the status setting device 1 requests the 
status table of a channel in which a user terminal participates 
5 from the dedicated terminal 6. In step S14, the dedicated 
terminal 6 receives a request from the status setting device 1 
and determines whether or not the status table that is a target 
of the request is set. Fig. 6 is an overall structural view of 
status tables and a common table stored in the dedicated terminal 

io- 6. In this figure, a status table is set to channels #CH1 and 
#CH2. A common table is used for other channels in place of a 
status table because.no status tables are set to them. 

Status tables are independently set to each channel. In 
this example, "Present/' "Outside work," "Dealing with a 

15 customer," and "Absent" are registered for #CH1. Prescribed 
identifiers are also registered for each status . Identifiers are 
used for determining an icon file to display a corresponding 
status. User attributes as well as settable statuses and 
identifiers are registered for the channel #CH2. For example, 

20 "Yes" or "No" is a settable status only by users with the 

"Student" attribute. Conversely, "Explaining" or "That's the 
point" is a settable status only by users with the "Teacher" 
attribute. 

In this example, four statuses "Present," "Away from 
25 his/her seat," "Busy," and "Absent" are registered in the common 



table. This common table is previously prepared, for example, 
in the system. If the status table of a requested channel has 
been set, step SI 5 ensues- Otherwise step S18 ensues as described 
below. 

In step SI 5, the dedicated terminal 6 sends the requested 
status table of a channel to the status setting device 1 
requesting the status table* An icon file that represents a 
status registered in the status table is also sent. The icon file 
will be described later. . 

In step S16, the status setting device 1 obtains the status table 
and the icon file* 

In step S17, the status setting device stores the obtained 
status table and the icon file in a storage part 16 such as a 
hard disk. This is because of utilizing the stored status table 
without accessing the dedicated terminal 6 if the same channel 
is participated in again. 

In step SI 8, the dedicated terminal 16 alternatively sends 
the common table because the requested status table of a channel 
is not registered. The icon file that represents a status 
registered in the status table is also sent. The status setting 
device 1, which received the common table, performs a similar 
process as when it received a status table. 

(3) Setting module 

Fig. 4 shows a flowchart showing the flow of processing 
performed by the setting module, with the setting module, the 



status setting device accepts the setting of a user status for 
a channel in which a user terminal participates. Incidentally, 
as shown in Fig- 7 to Fig. 9, the status setting device 1 displays 
a Self Status Setting Menubar on the conversation window. The 
5 conversation window is a window displaying the conversation in 
the channel. 

In step S21, the status setting device 1 waits for the Self 
Status Menubar to be pressed, and step S22 ensues after the Self 
=k Status Menubar is pressed. 

• .10^ In step S22 f the^status setting device 1 displays the setting 

f% i 

iff window for setting the self status. An example of the setting 

\1 ;.. window is shown in Fig. 7 to Fig, 9. On the setting window, 

E contents of the status table of a channel to be displayed are 

N= displayed.. If the status table is not registered, the contents 

g 15 of the common . table are displayed. 

O If the user terminal participates in plural channels, the 

setting windows are displayed for each channel. Fig. 7 is an 
example of a setting window when the IRC client 2 independently 
displays plural conversation windows. The self status setting 
20 menu bar and the setting window is independently displayed on 
each conversation window. 

Fig. 8 is an example of a setting window showing that one 
conversation window can be independently displayed even if the 
IRC client 2 participates in more than one channel. Contents of 
25 the status table of a current channel to be displayed are 
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displayed on the setting screen. If the current channel changes 
to another channel, contents of the current channel changes. 
Contents to be displayed are read in the display buffer when a 
current channel changes to another channel. 
5 Fig. 9 shows setting windows which are displayed when 

settable statuses vary depending on a user attribute. In this 
figure , setting windows for a teacher and students on the 
aforementioned online class channel CH#2- are shown. In the 
setting windows, visually-distinctive settable statuses and 
io : unsettable statuses are displayed corresponding to user 
. . attributes. Alternatively, displaying only settable statuses 
is also possible. 

Furthermore, user attributes can be distinguished on both 
the dedicated terminal and the user terminals. For example, for 
15 a channel for an online class, the network address of the user 
terminal 4 used by a teacher is previously registered in the 
dedicated terminal 4 to recognize other user terminals as 
students. 

In step S23, the status setting device 1 determines 
20 whether or not any of the statuses is selected on the setting 
window. If the status setting device 1 determines that the result 
is "Yes," step S24 ensues. If the status setting device 1 
determines that the result is "No," the status setting device 
1 repeats the determination and waits for any of the statuses 
25 to be selected. 
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In step S24, the status setting device 1 stores a set self 
status by relating it to a channel. The status setting device 
notifies of other user terminals 4 in the channel the set self 
status with a chat support device 3, In other user terminals 4, 
5 the chat support device 3 displays the notified user status with 
an icon. 

(4) Registration module 

Fig. 5 is a flowchart showing a flow of processing 
performed .by the registration module. In this process, the 

10 status setting device 1 receives the setting of the status table. 
As shown in Fig. 8, the status setting device displays the 
Register button on the Menubar. 

In step S31, the status setting device waits for the 
Register button to be pressed, and step S32 ensues when the 

15 button is pressed.- Incidentally, it is preferable to limit the 
use of Register button according to a user attribute or other 
authorities in a channel. Granting the authority to use the 
Register button to an administrator or users having a particular 
attribute is an example. It is preferable that if a user does 

20 not have the authority to use the Register button, indication 
of such is displayed by graying the Register button (not shown 
in the figure) . 

In step S32, the status setting device 1 displays the 
"registration window" for registering a status in a status table. 

25 Fig. 10 shows a display example of a Register Window. In this 
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example, a Main Window 30 , an Add button, a Register button, and 
a Cancel button are arranged on the Register Window. 

A user adds a necessary status to the Main Window 3 0 one 
after another with the Add button. When the "Register" button 
5 is pressed to finish the registration, contents written in the 
Main Window 30 are transmitted to the dedicated terminal 6. When 
the Cancel button is pressed, contents of the Main Window 30 are 
cleared and the Register Window is closed. 

in step S33, the status setting device 1 determines 
10 whether or not the Add button is pressed in the Register Window. 

in ■'■ If the status setting device 1 determines that the result is 

i y 

M: "Yes," step S34 ensues. If the status setting device 1 determines 

%~ i 

s that the result is "No," step S37 ensues, which will be described 

5: later. 

15 In step S34, the status setting device 1 displays the Add 

Window 40 to receive a status setting. Users can select a status 
to be registered and icon information in the Add Window 40. Icon 
information is an item for setting an icon file displaying a 
status to be registered. In this setting example, the "Hard to 
20 understand" is displayed with the icon file identified by 
"_udn.ico." Furthermore, if necessary, users can set user 
attributes . 

In step S3 5, the status setting device waits for an OK 
button or the Cancel button to be pressed. When the OK button 
25 is pressed in the Add Window, established contents are written 
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in the Main Window 30 and step S36 ensues, when the Cancel button 
is pressed, the aforementioned step S33 ensues. 

In step S36, the status setting device 1 displays contents 
set on the Add Window 40 in the Main Window 30. Then the status 
5 setting device 1 waits for the Add button, the Register button, 
or the Cancel button to be pressed on the Main Window 30. 

In step S37, the status setting device 1 determines 
whether or not the Register button is pressed in the Register 
Window* If the status setting device 1 determines that the result 
•10 is "Yes," then step S38 ensues. If the status setting device 1 
determines that the result is "No," then step S39, which will 
be described later, ensues. 

In step S38, the status setting device transmits contents 
written in the Main window 3 0 to the dedicated terminal 6. The 
15 dedicated terminal 6 stores the transmitted contents with a 
channel name as a status table. 

In step 39, the status setting device 1 recognizes that 
the Cancel button is pressed and closes the Register Window. 
( 5 ) Symbol program 
20 As mentioned above, the chat support device 3 displays 

statuses set by the status setting. In the present embodiment, 
the chat support device 3 displays a status with an icon file 
specified by the symbol program 15, or an icon. The symbol 
program 15 specifies an icon file according to a user status 
25 obtained from an icon list and the chat support device 3 . 
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Fig* 11 is a conceptual explanatory diagram of an icon list 
stored by the dedicated terminal 6. In the icon list, all 
available icon files are related to icon names and stored. There 
are two types of icons in the icon file; a fundamental icon 
5 representing a user, and a status icon. Several types of 
fundamental icons are prepared. For each fundamental icon, 
status icons indicating a user status with the fundamental icon 
are prepared. 

For example > an icon file identified by an icon file name . 

10 "Manl.ico" in the Fig. 11 is a fundamental icon. The status icon 
is identified by combination of the file name of the fundamental 
icon and an identifier i.e. "Manl_* . ico. " Wherein is 

an arbitrary string. An icon file and its file name which are 
necessary to display a status registered in the status table are 

15 transmitted from the dedicated terminal 6 to the user terminal 
4 . 

The symbol program 15 creates a virtual space table on each 
channel in which a user terminal participates and administrates 
status icons representing a user status. Fig. 12 is a conceptual 
20 explanatory diagram of the virtual space table. In this example, 
the IRC client 2 participates in channels #CHl, #CH2, and #CH3 . 
The virtual space table correlatively stores user names, user 
statuses, fundamental icons of users, and status icons of users 
in a channel in which a user terminal participates - 
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Identifiers for identifying users in a channel such as 
nicknames can be used as user names. Statuses of other users 
obtained from the chat support device 3 are described in 
"Status*" A name of a fundamental icon representing oneself in 
5 a channel is described in "Fundamental icon." A file name of a 
status icon representing a status of each user is described in 
"Status icon." A Status icon is determined based on a 
fundamental icon and a status of a user. 
^ The following specifically describes the determination 

; 10 method of a status icon. Assume that the status table of the 
Sq". channel #CH1 is as shown in Fig. 6. In Fig. 12, the user "John" 

l hi 

U is "Absent" in the channel #CHl . The status icon displaying the 

£ "absence" of John is determined as follows. The fundamental icon 

of John is "Manl.ico." The identifier displaying the status . 
■C 5 15 "Absent" in the channel #CH1 is "off." Therefore, the file name 
^ of the status icon displaying the absence of John is determined 

as "Manl_of f . ico. " The chat support device 3 displays the user 
status with the determined status icon. 

It is also possible to display a user status by displaying 
20 a combination of a symbol representing a status and a fundamental 
icon. The following describes the determination method of a 
status icon in the above case. Fig. 13 is conceptual explanatory 
diagram of another icon list stored in the dedicated terminal 
6. The dedicated terminal 6 stores a fundamental icon list (a) 
25 and an auxiliary icon list (b). In the fundamental list, all 

- 23 - 



fundamental icons are stored with icon file names. In the 
auxiliary icon list, auxiliary icons representing statuses are 
stored with icon file names. Herein an identifier /l *.ico' / 
representing a status is used for file names of auxiliary icons. 
A status icon representing a user status is displayed by 
combining a fundamental icon representing a user with an 
auxiliary icon representing a status. 

Again, consider the user "John" that is the "Absent" 
status in the channel #CHl to explain the displaying method of 
the status icon. The fundamental icon of John is- "Manl . ico. " The 
identifier representing the status "Absent" in the channel #CH1 
is "off." Therefore, the file name of the auxiliary icon 
representing the status "Absent" is "off .ico." The combination 
of the fundamental icon "Manl.ico" and the auxiliary icon 
"off .icon" is determined as the status icon to be displayed. The 
chat support device 3 displays the user status with the 
determined fundamental icon and the auxiliary icon. 

Another method is updating a fundamental icon by a module. 
For example, prepare an icon update module corresponding to an 
identifier. When a user status changes, the fundamental icon of 
the relevant user is updated with a module identified by the 
identifier and the status icon is displayed. 

In the above embodiment, a dedicated terminal 6 has been 
provided. However, a configuration without dedicated terminals 
6 is also possible. Fig. 14 is a function configuration diagram 
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of the status setting system with respect to the second 
embodiment. The status table and common table are previously 
stored in a storage part 16 by some method. Some method means 
that these tables are set by users in advance and are stored in 
5 each terminal via a recording medium such as CD or a network 5 , 
for example. When the user status is displayed with an icon, the 
icon list is stored in the status setting device 1. 

In this case, the status setting device 1 will not request 
obtaining a status table even if a new user terminal participates. 

10 in a channel. The status setting device determines whether or 
not a status table in which a new user terminal participates is 
stored, and reads a common table if it is not stored. Other 
functions are the same as the above first embodiment. 

(B) In the above embodiment, a case in which a conversation 

15 device is an IRC client has been exemplified. However, this 
invention is applicable to other conversation devices. The 
following describes a case in which a browser is used as a 
conversation device to perform WebChat. 

Fig. 15 is a function configuration diagram of a status setting 
20 system with respect to the third embodiment. This status setting 
system is configured by applying this invention to a WebChat 
system composed of a browser 2, a WebChat server 7, and a network 
5. In a WebChat system, users share a webpage and send and receive 
character messages. In the figure, same signs accompany 
25 components having same functions as in the first embodiment. 
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Status tables and common tables suitable to each webpage 
are stored in a WebChat server 7. A JavaTM program (obtaining 
program 71) directing obtaining a status table and a JavaTM 
program setting the status table (setting program 72) are 
5 embedded in the webpage provided by the WebChat server 7* The 
status table to be read is assigned in the obtaining module 71. 

The following process is performed after a browser 2 
obtains a webpage from the WebChat server 7. First, the obtaining 
g- \ . module embedded in a webpage is activated. By this, the browser 
Hj| to 2 obtains the status table in the WebChat server 7. The setting 

•%} 

U1 module 72 displays "Self Status Setting Menubar" on the 

Mi 

-H- conversation window. When the Self Status Setting Menubar is 

f pressed, the setting module 72 displays the setting window in 

Jf ; the same way as mentioned above and acdepts the user status 

!ff 15 setting. A registration module 1 and a symbol program 15 are 
™ provided for the browser 2. These functions are similar to the 

first embodiment. 

(C) The recording medium to record modules to execute the 
methods in the present invention is included in the present 

20 invention. Herein a floppy disk, a hard disk, a semiconductor 
memory, CD-ROM, DVD, a magneto-optic disk (MO), etc. are 
examples of a recording medium. 

(D) The transmission medium to transmit modules for 
executing the methods in the present invention is included in 

25 the present invention. Herein a transmission medium is a 
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communication medium on a computer network system (LAN, Internet, 
or radio communication network) for transmitting and providing 
module information as a carrier wave as a fiber optic, or a radio 
circuit. 

Status notification suitable to properties of a virtual 
space is enabled by using the present invention because users 
in the virtual space can set for each virtual space their self 
statuses suitable to properties of the virtual space. 

While only selected embodiments have been chosen to 
illustrate the present invention, to those skilled in the art 
it will be apparent from this disclosure that various changes 
and modifications can be made herein without departing from the 
scope of the invention as defined in the appended claims • 
Furthermore, the foregoing description of the embodiments set 
forth in the present invention is provided for illustration only, 
and not for the purpose of limiting the invention as defined by 
the appended claims and their equivalents . 



